Vzorec opazovalca z JavaScript WeakRef: Gradnja pomnilniško zavednih sistemov dogodkov

V svetu sodobnega spletnega razvoja so enostranske aplikacije (SPA) postale standard za ustvarjanje dinamičnih in odzivnih uporabniških izkušenj. Te aplikacije pogosto tečejo dlje časa, upravljajo kompleksna stanja in obdelujejo nešteto uporabniških interakcij. Vendar pa ta dolgotrajnost prinaša skrito ceno: povečano tveganje za uhajanje pomnilnika. Uhajanje pomnilnika, kjer aplikacija zadržuje pomnilnik, ki ga ne potrebuje več, lahko sčasoma poslabša delovanje, kar vodi v počasnost, zrušitve brskalnika in slabo uporabniško izkušnjo. Eden najpogostejših virov teh uhajanj leži v temeljnem oblikovalskem vzorcu: vzorcu opazovalca.

Vzorec opazovalca je temelj dogodkovno vodene arhitekture, ki objektom (opazovalcem) omogoča, da se naročijo na posodobitve osrednjega objekta (subjekta) in jih prejemajo. Je eleganten, preprost in neverjetno uporaben. Toda njegova klasična implementacija ima ključno napako: subjekt ohranja močne reference na svoje opazovalce. Če opazovalec ni več potreben preostalemu delu aplikacije, a ga razvijalec pozabi izrecno odjaviti od subjekta, ne bo nikoli zbran s strani zbiralnika smeti. Ostane ujet v pomnilniku, duh, ki straši v zmogljivosti vaše aplikacije.

Tu sodobni JavaScript s svojimi funkcijami iz ECMAScript 2021 (ES12) ponuja zmogljivo rešitev. Z uporabo WeakRef in FinalizationRegistry lahko zgradimo pomnilniško zaveden vzorec opazovalca, ki se samodejno čisti in tako preprečuje ta pogosta uhajanja. Ta članek je poglobljen vpogled v to napredno tehniko. Raziskali bomo problem, razumeli orodja, zgradili robustno implementacijo iz nič ter razpravljali o tem, kdaj in kje bi morali ta močan vzorec uporabiti v svojih globalnih aplikacijah.

Razumevanje osrednjega problema: Klasični vzorec opazovalca in njegov pomnilniški odtis

Preden lahko cenimo rešitev, moramo v celoti razumeti problem. Vzorec opazovalca, znan tudi kot vzorec izdajatelj-naročnik, je zasnovan za razdruževanje komponent. Subjekt (ali izdajatelj) vzdržuje seznam svojih odvisnikov, imenovanih opazovalci (ali naročniki). Ko se stanje subjekta spremeni, samodejno obvesti vse svoje opazovalce, običajno s klicem določene metode na njih, kot je update().

Poglejmo si preprosto, klasično implementacijo v JavaScriptu.

Preprosta implementacija subjekta

Tukaj je osnovni razred Subject. Ima metode za naročanje, odjavljanje in obveščanje opazovalcev.

class ClassicSubject {

  constructor() {

    this.observers = [];

  }

 

  subscribe(observer) {

    this.observers.push(observer);

    console.log(`${observer.name} se je naročil.`);

  }

 

  unsubscribe(observer) {

    this.observers = this.observers.filter(obs => obs !== observer);

    console.log(`${observer.name} se je odjavil.`);

  }

 

  notify(data) {

    console.log('Obveščanje opazovalcev...');

    this.observers.forEach(observer => observer.update(data));

  }

}

In tukaj je preprost razred Observer, ki se lahko naroči na subjekt.

class Observer {

  constructor(name) {

    this.name = name;

  }

 

  update(data) {

    console.log(`${this.name} je prejel podatke: ${data}`);

  }

}

Skrita nevarnost: Vztrajajoče reference

Ta implementacija deluje povsem v redu, dokler skrbno upravljamo življenjski cikel naših opazovalcev. Problem nastane, ko tega ne storimo. Razmislite o pogostem scenariju v veliki aplikaciji: dolgotrajna globalna shramba podatkov (subjekt) in začasna komponenta uporabniškega vmesnika (opazovalec), ki prikazuje nekatere od teh podatkov.

Simulirajmo ta scenarij:

const dataStore = new ClassicSubject();

 

function manageUIComponent() {

  let chartComponent = new Observer('ChartComponent');

  dataStore.subscribe(chartComponent);

 

  // Komponenta opravlja svoje delo...

 

  // Zdaj uporabnik odide drugam in komponenta ni več potrebna.

  // Razvijalec lahko pozabi dodati kodo za čiščenje:

  // dataStore.unsubscribe(chartComponent);

 

  chartComponent = null; // Sprostimo našo referenco na komponento.

}

 

manageUIComponent();

 

// Kasneje v življenjskem ciklu aplikacije...

dataStore.notify('Novi podatki so na voljo!');

V funkciji `manageUIComponent` ustvarimo `chartComponent` in ga naročimo na naš `dataStore`. Kasneje `chartComponent` nastavimo na `null`, s čimer signaliziramo, da smo z njim končali. Pričakujemo, da bo JavaScript zbiralnik smeti (GC) videl, da ni več referenc na ta objekt, in sprostil njegov pomnilnik.

Toda obstaja še ena referenca! Polje `dataStore.observers` še vedno vsebuje neposredno, močno referenco na objekt `chartComponent`. Zaradi te ene same vztrajajoče reference zbiralnik smeti ne more sprostiti pomnilnika. Objekt `chartComponent` in vsi viri, ki jih drži, bodo ostali v pomnilniku ves čas življenja `dataStore`. Če se to dogaja večkrat – na primer vsakič, ko uporabnik odpre in zapre modalno okno – bo poraba pomnilnika aplikacije rasla v nedogled. To je klasično uhajanje pomnilnika.

Novo upanje: Predstavitev WeakRef in FinalizationRegistry

ECMAScript 2021 je predstavil dve novi funkciji, ki sta posebej zasnovani za obvladovanje tovrstnih izzivov pri upravljanju pomnilnika: `WeakRef` in `FinalizationRegistry`. Sta napredni orodji in ju je treba uporabljati previdno, a za naš problem z vzorcem opazovalca sta popolna rešitev.

Kaj je WeakRef?

Objekt `WeakRef` hrani šibko referenco na drug objekt, imenovan njegov cilj. Ključna razlika med šibko referenco in običajno (močno) referenco je naslednja: šibka referenca ne preprečuje, da bi bil njen ciljni objekt zbran s strani zbiralnika smeti.

Če so edine reference na objekt šibke reference, lahko JavaScript pogon uniči objekt in sprosti njegov pomnilnik. To je točno tisto, kar potrebujemo za rešitev našega problema z opazovalcem.

Za uporabo `WeakRef` ustvarite njegovo instanco in konstruktorju posredujete ciljni objekt. Za kasnejši dostop do ciljnega objekta uporabite metodo `deref()`.

let targetObject = { id: 42 };

const weakRefToObject = new WeakRef(targetObject);

 

// Za dostop do objekta:

const retrievedObject = weakRefToObject.deref();

 

if (retrievedObject) {

  console.log(`Objekt je še vedno živ: ${retrievedObject.id}`); // Izhod: Objekt je še vedno živ: 42

} else {

  console.log('Objekt je bil zbran s strani zbiralnika smeti.');

}

Ključno je, da lahko `deref()` vrne `undefined`. To se zgodi, če je bil `targetObject` zbran s strani zbiralnika smeti, ker nanj ne obstajajo več močne reference. To obnašanje je temelj našega pomnilniško zavednega vzorca opazovalca.

Kaj je FinalizationRegistry?

Medtem ko `WeakRef` omogoča, da se objekt zbere, nam ne daje čistega načina, da bi vedeli, kdaj je bil zbran. Lahko bi občasno preverjali `deref()` in odstranjevali `undefined` rezultate iz našega seznama opazovalcev, vendar je to neučinkovito. Tu na pomoč priskoči `FinalizationRegistry`.

`FinalizationRegistry` vam omogoča registracijo povratne funkcije, ki bo klicana, potem ko je bil registriran objekt zbran s strani zbiralnika smeti. To je mehanizem za čiščenje po 'smrti' objekta.

Deluje takole:

1. Ustvarite register s povratno funkcijo za čiščenje.
2. Z metodo `register()` registrirate objekt v registru. Zagotovite lahko tudi `heldValue`, kar je podatek, ki bo posredovan vaši povratni funkciji, ko bo objekt zbran. Ta `heldValue` ne sme biti neposredna referenca na sam objekt, saj bi to izničilo namen!

// 1. Ustvarite register s povratno funkcijo za čiščenje

const registry = new FinalizationRegistry(heldValue => {

  console.log(`Objekt je bil zbran. Žeton za čiščenje: ${heldValue}`);

});

 

(function() {

  let objectToTrack = { name: 'Temporary Data' };

  let cleanupToken = 'temp-data-123';

 

  // 2. Registrirajte objekt in zagotovite žeton za čiščenje

  registry.register(objectToTrack, cleanupToken);

 

  // objectToTrack tukaj preneha biti v obsegu

})();

 

// Nekje v prihodnosti, po zagonu zbiralnika smeti, se bo v konzolo izpisalo:

// "Objekt je bil zbran. Žeton za čiščenje: temp-data-123"

Pomembna opozorila in najboljše prakse

Preden se poglobimo v implementacijo, je ključno razumeti naravo teh orodij. Obnašanje zbiralnika smeti je močno odvisno od implementacije in je nedeterministično. To pomeni:

• Ne morete napovedati, kdaj bo objekt zbran. To se lahko zgodi sekunde, minute ali celo dlje po tem, ko postane nedosegljiv.
• Ne morete se zanašati na to, da se bodo povratne funkcije `FinalizationRegistry` izvedle pravočasno ali predvidljivo. Namenjene so čiščenju, ne pa kritični logiki aplikacije.
• Prekomerna uporaba `WeakRef` in `FinalizationRegistry` lahko oteži razumevanje kode. Vedno dajte prednost enostavnejšim rešitvam (kot so eksplicitni klici `unsubscribe`), če so življenjski cikli objektov jasni in obvladljivi.

Te funkcije so najprimernejše za situacije, kjer je življenjski cikel enega objekta (opazovalca) resnično neodvisen in neznan drugemu objektu (subjektu).

Gradnja vzorca `WeakRefObserver`: Implementacija korak za korakom

Sedaj združimo `WeakRef` in `FinalizationRegistry` ter zgradimo pomnilniško varen razred `WeakRefSubject`.

1. korak: Struktura razreda `WeakRefSubject`

Naš novi razred bo shranjeval `WeakRef` reference na opazovalce namesto neposrednih referenc. Imel bo tudi `FinalizationRegistry` za samodejno čiščenje seznama opazovalcev.

class WeakRefSubject {

  constructor() {

    this.observers = new Set(); // Uporaba Seta za lažje odstranjevanje

 

    // Povratna funkcija za dokončanje. Prejme vrednost, ki jo podamo med registracijo.

    // V našem primeru bo ta vrednost sama instanca WeakRef.

    this.cleanupRegistry = new FinalizationRegistry(weakRefObserver => {

      console.log('Finalizer: Opazovalec je bil zbran s strani zbiralnika smeti. Čiščenje...');

      this.observers.delete(weakRefObserver);

    });

  }

}

Za naš seznam opazovalcev uporabljamo `Set` namesto `Array`. To je zato, ker je brisanje elementa iz `Seta` veliko bolj učinkovito (povprečna časovna kompleksnost O(1)) kot filtriranje `Array` (O(n)), kar bo koristno v naši logiki čiščenja.

2. korak: Metoda `subscribe`

Metoda `subscribe` je tam, kjer se začne čarovnija. Ko se opazovalec naroči, bomo:

1. Ustvarili `WeakRef`, ki kaže na opazovalca.
2. Dodali ta `WeakRef` v naš `Set` opazovalcev.
3. Registrirali originalni objekt opazovalca v naš `FinalizationRegistry`, pri čemer bomo kot `heldValue` uporabili novo ustvarjeni `WeakRef`.

// Znotraj razreda WeakRefSubject...

subscribe(observer) {

  // Preveri, ali opazovalec s to referenco že obstaja

  for (const ref of this.observers) {

    if (ref.deref() === observer) {

      console.warn('Opazovalec je že naročen.');

      return;

    }

  }

 

  const weakRefObserver = new WeakRef(observer);

  this.observers.add(weakRefObserver);

 

  // Registriraj originalni objekt opazovalca. Ko bo zbran,

  // bo klicana povratna funkcija z `weakRefObserver` kot argumentom.

  this.cleanupRegistry.register(observer, weakRefObserver);

 

  console.log('Opazovalec se je naročil.');

}

Ta postavitev ustvari pametno zanko: subjekt hrani šibko referenco na opazovalca. Register hrani močno referenco na opazovalca (interno), dokler ta ni zbran s strani zbiralnika smeti. Ko je zbran, se sproži povratna funkcija registra z instanco šibke reference, ki jo nato lahko uporabimo za čiščenje našega `Set` opazovalcev.

3. korak: Metoda `unsubscribe`

Tudi s samodejnim čiščenjem bi morali še vedno zagotoviti ročno metodo `unsubscribe` za primere, ko je potrebno deterministično odstranjevanje. Ta metoda bo morala najti pravilen `WeakRef` v našem setu tako, da dereferencira vsakega posebej in ga primerja z opazovalcem, ki ga želimo odstraniti.

// Znotraj razreda WeakRefSubject...

unsubscribe(observer) {

  let refToRemove = null;

  for (const weakRef of this.observers) {

    if (weakRef.deref() === observer) {

      refToRemove = weakRef;

      break;

    }

  }

 

  if (refToRemove) {

    this.observers.delete(refToRemove);

    // POMEMBNO: Prav tako se moramo odregistrirati iz finalizerja,

    // da preprečimo nepotrebno izvajanje povratne funkcije kasneje.

    this.cleanupRegistry.unregister(observer);

    console.log('Opazovalec se je ročno odjavil.');

  }

}

4. korak: Metoda `notify`

Metoda `notify` iterira čez naš set `WeakRef`-ov. Za vsakega poskusi `deref()`, da dobi dejanski objekt opazovalca. Če `deref()` uspe, to pomeni, da je opazovalec še vedno živ, in lahko kličemo njegovo metodo `update`. Če vrne `undefined`, je bil opazovalec zbran, in ga lahko preprosto ignoriramo. `FinalizationRegistry` bo sčasoma odstranil njegov `WeakRef` iz seta.

// Znotraj razreda WeakRefSubject...

notify(data) {

  console.log('Obveščanje opazovalcev...');

  for (const weakRefObserver of this.observers) {

    const observer = weakRefObserver.deref();

    if (observer) {

      // Opazovalec je še vedno živ

      observer.update(data);

    } else {

      // Opazovalec je bil zbran s strani zbiralnika smeti.

      // FinalizationRegistry bo poskrbel za odstranitev te šibke reference iz seta.

      console.log('Med obveščanjem najdena referenca na mrtvega opazovalca.');

    }

  }

}

Sestavljanje vsega skupaj: Praktičen primer

Vrnimo se k našemu scenariju komponente uporabniškega vmesnika, vendar tokrat z uporabo našega novega `WeakRefSubject`. Za enostavnost bomo uporabili isti razred `Observer` kot prej.

// Isti preprost razred Observer

class Observer {

  constructor(name) {

    this.name = name;

  }

  update(data) {

    console.log(`${this.name} je prejel podatke: ${data}`);

  }

}

Sedaj pa ustvarimo globalno podatkovno storitev in simulirajmo začasen pripomoček uporabniškega vmesnika.

const globalDataService = new WeakRefSubject();

function createAndDestroyWidget() {

  console.log('--- Ustvarjanje in naročanje novega pripomočka ---');

  let chartWidget = new Observer('RealTimeChartWidget');

  globalDataService.subscribe(chartWidget);

 

  // Pripomoček je zdaj aktiven in bo prejemal obvestila

  globalDataService.notify({ price: 100 });

 

  console.log('--- Uničevanje pripomočka (sprostitev naše reference) ---');

  // S pripomočkom smo končali. Našo referenco nastavimo na null.

  // NI nam treba klicati unsubscribe().

  chartWidget = null;

}

createAndDestroyWidget();

console.log('--- Po uničenju pripomočka, pred zbiranjem smeti ---');

globalDataService.notify({ price: 105 });

Po zagonu `createAndDestroyWidget()` se na objekt `chartWidget` zdaj sklicuje samo `WeakRef` znotraj našega `globalDataService`. Ker je to šibka referenca, je objekt zdaj primeren za zbiranje smeti.

Ko se bo zbiralnik smeti sčasoma zagnal (česar ne moremo napovedati), se bosta zgodili dve stvari:

1. Objekt `chartWidget` bo odstranjen iz pomnilnika.
2. Sprožila se bo povratna funkcija našega `FinalizationRegistry`, ki bo nato odstranila zdaj mrtvo `WeakRef` iz seta `globalDataService.observers`.

Če ponovno kličemo `notify`, potem ko je zbiralnik smeti deloval, bo klic `deref()` vrnil `undefined`, mrtvi opazovalec bo preskočen, aplikacija pa bo še naprej delovala učinkovito brez uhajanja pomnilnika. Uspešno smo ločili življenjski cikel opazovalca od subjekta.

Kdaj uporabiti (in kdaj se izogibati) vzorcu `WeakRefObserver`

Ta vzorec je močan, vendar ni univerzalna rešitev. Uvaja kompleksnost in se zanaša na nedeterministično obnašanje. Ključno je vedeti, kdaj je pravo orodje za delo.

Idealni primeri uporabe

• Dolgotrajni subjekti in kratkotrajni opazovalci: To je kanonični primer uporabe. Globalna storitev, shramba podatkov ali predpomnilnik (subjekt), ki obstaja ves življenjski cikel aplikacije, medtem ko se številne komponente uporabniškega vmesnika, začasni delavci ali vtičniki (opazovalci) pogosto ustvarjajo in uničujejo.
• Mehanizmi predpomnjenja: Predstavljajte si predpomnilnik, ki preslika kompleksen objekt v nek izračunan rezultat. Za ključni objekt lahko uporabite `WeakRef`. Če je originalni objekt zbran s strani zbiralnika smeti iz preostalega dela aplikacije, lahko `FinalizationRegistry` samodejno počisti ustrezen vnos v vašem predpomnilniku, kar preprečuje nabiranje pomnilnika.
• Arhitekture z vtičniki in razširitvami: Če gradite osrednji sistem, ki omogoča modulom tretjih oseb, da se naročijo na dogodke, uporaba `WeakRefObserver` doda plast odpornosti. Preprečuje, da bi slabo napisan vtičnik, ki pozabi na odjavo, povzročil uhajanje pomnilnika v vaši osrednji aplikaciji.
• Povezovanje podatkov z elementi DOM: V scenarijih brez deklarativnega ogrodja boste morda želeli povezati nekatere podatke z elementom DOM. Če to shranite v preslikavi z elementom DOM kot ključem, lahko ustvarite uhajanje pomnilnika, če je element odstranjen iz DOM, vendar je še vedno v vaši preslikavi. `WeakMap` je tu boljša izbira, vendar je princip enak: življenjski cikel podatkov bi moral biti vezan na življenjski cikel elementa, ne obratno.

Kdaj se držati klasičnega opazovalca

• Tesno povezani življenjski cikli: Če se subjekt in njegovi opazovalci vedno ustvarjajo in uničujejo skupaj ali znotraj istega obsega, sta dodatna obremenitev in kompleksnost `WeakRef` nepotrebna. Preprost, ekspliciten klic `unsubscribe()` je bolj berljiv in predvidljiv.
• Kritične poti z visoko zmogljivostjo: Metoda `deref()` ima majhno, a ne-ničelno ceno zmogljivosti. Če obveščate na tisoče opazovalcev stokrat na sekundo (npr. v zanki igre ali vizualizaciji podatkov z visoko frekvenco), bo klasična implementacija z neposrednimi referencami hitrejša.
• Enostavne aplikacije in skripte: Za manjše aplikacije ali skripte, kjer je življenjska doba aplikacije kratka in upravljanje pomnilnika ni pomembna skrb, je klasični vzorec enostavnejši za implementacijo in razumevanje. Ne dodajajte kompleksnosti, kjer ni potrebna.
• Ko je potrebno deterministično čiščenje: Če morate izvesti dejanje točno v trenutku, ko se opazovalec odklopi (npr. posodabljanje števca, sprostitev določenega strojnega vira), morate uporabiti ročno metodo `unsubscribe()`. Nedeterministična narava `FinalizationRegistry` ga naredi neprimernega za logiko, ki se mora izvajati predvidljivo.

Širše posledice za arhitekturo programske opreme

Uvedba šibkih referenc v visokonivojski jezik, kot je JavaScript, signalizira zorenje platforme. Razvijalcem omogoča gradnjo bolj sofisticiranih in odpornih sistemov, zlasti za dolgotrajne aplikacije. Ta vzorec spodbuja premik v arhitekturnem razmišljanju:

• Prava razdružitev: Omogoča raven razdružitve, ki presega zgolj vmesnik. Zdaj lahko razdružimo same življenjske cikle komponent. Subjektu ni več treba vedeti ničesar o tem, kdaj so njegovi opazovalci ustvarjeni ali uničeni.
• Odpornost po zasnovi: Pomaga graditi sisteme, ki so bolj odporni na napake programerjev. Pozabljen klic `unsubscribe()` je pogosta napaka, ki jo je lahko težko izslediti. Ta vzorec zmanjšuje celoten razred teh napak.
• Omogočanje avtorjem ogrodij in knjižnic: Za tiste, ki gradijo ogrodja, knjižnice ali platforme za druge razvijalce, so ta orodja neprecenljiva. Omogočajo ustvarjanje robustnih API-jev, ki so manj dovzetni za zlorabo s strani uporabnikov knjižnice, kar vodi v stabilnejše aplikacije na splošno.

Zaključek: Zmogljivo orodje za sodobnega JavaScript razvijalca

Klasični vzorec opazovalca je temeljni gradnik oblikovanja programske opreme, vendar je njegova odvisnost od močnih referenc že dolgo vir subtilnih in frustrirajočih uhajanj pomnilnika v JavaScript aplikacijah. S prihodom `WeakRef` in `FinalizationRegistry` v ES2021 imamo zdaj orodja za premagovanje te omejitve.

Potovali smo od razumevanja temeljnega problema vztrajajočih referenc do gradnje popolnega, pomnilniško zavednega `WeakRefSubject` iz nič. Videli smo, kako `WeakRef` omogoča, da se objekti zbirajo s strani zbiralnika smeti, tudi ko so 'opazovani', in kako `FinalizationRegistry` zagotavlja samodejni mehanizem čiščenja, da ohranja naš seznam opazovalcev neokrnjen.

Vendar z veliko močjo pride velika odgovornost. To so napredne funkcije, katerih nedeterministična narava zahteva skrbno presojo. Niso nadomestilo za dobro načrtovanje aplikacij in skrbno upravljanje življenjskega cikla. Toda ko se uporabijo za prave probleme – kot je upravljanje komunikacije med dolgotrajnimi storitvami in efemernimi komponentami – je vzorec opazovalca z WeakRef izjemno močna tehnika. Z obvladovanjem te tehnike lahko pišete bolj robustne, učinkovite in razširljive JavaScript aplikacije, pripravljene na zahteve sodobnega, dinamičnega spleta.